Should probably check !isEmpty here as well.

We now do a

      if (!$content_entity->hasField($base_field)) {
        return;
      }

      // Consider indexing each entity referenced through this field.
      foreach ($content_entity->$base_field->referencedEntities() as $target_entity) { ... }

I think calling ->referencedEntities() will fail very gracefully if it's empty.

This looks to be outside of the foreach where it's instantiated and could be possibly be undefined?

When enabling the processor I get:

Warning: Declaration of Drupal\islandora\Plugin\search_api\processor\Property\EntityReferenceWithUriProperty::create(Symfony\Component\DependencyInjection\ContainerInterface $container, array $configuration) should be compatible with Drupal\Core\TypedData\DataDefinition::create($type) in include() (line 18 of modules/contrib/islandora/src/Plugin/search_api/processor/Property/EntityReferenceWithUriProperty.php).

include('/opt/www/drupal/modules/contrib/islandora/src/Plugin/search_api/processor/Property/EntityReferenceWithUriProperty.php') (Line: 578)
Composer\Autoload\ClassLoader::Composer\Autoload\{closure}('/opt/www/drupal/modules/contrib/islandora/src/Plugin/search_api/processor/Property/EntityReferenceWithUriProperty.php') (Line: 432)

search_api's properties are intended to be a data definition and appear to not be architected to directly support DI. Normally when wanting to inject you would need to implement the ContainerFactoryPluginInterface which is not possible here.

Is a few options which could work around this such as implementing your own static factory method to instantiate the property or re-working the plugin itself to pass in the requested values directly as opposed to the property itself. Alternative could be just making static functions in the property class as opposed to injecting (@adam-vessey clarify if I'm off here?)

I think we discussed how ContainerFactoryPluginInterface doesn't work here because the Property is not a Plugin, when I was doing this.

So without DI, then we have these ugly things:

$entity_type_manager = \Drupal::entityTypeManager()->getStorage('field_config')

and

$utils = \Drupal::service('islandora.utils');

Is this what you were referring to with "just making static functions in the property class as opposed to injecting"? I'm fine with that.

"Implementing my own static factory method" sounds hard. :(

"plugin itself to pass in the requested values directly as opposed to the property itself" I'm not sure I follow. Right now the plugin does

$properties[$fieldname] = new EntityReferenceWithUriProperty($definition, $this->entityTypeManager, $this->utils);

and the Property's __construct() function accepts that signature... OOOOHH you're saying we could maybe remove the Property's __create() function?

implementing [a] static factory method

Really isn't that difficult. As in, it's effectively the same as ContainerFactoryPluginInterface, just without being passed the container... so similarly have a static method like the ::create() it described, and then use the \Drupal global class dealio to access things from the container. So, something like:

class EntityReferenceWithUriProperty [extends whatever class and implements whatever interfaces] {
  [...]
  public static function createInstance(array $definition) {
    return new static(
      $definition,
      // \Drupal::entityTypeManager() could probably equally work, anyway.
      \Drupal::service('entity_type.manager'),
      \Drupal::service('islandora.utils')
    );
  }
}

Sure, it might does still do a bit of binding with Drupal proper; however, the bigger issue is allowing the services to be passed in the constructor that this would address (facilitating testability, should it be pursued), but doing so without requiring invoking classes to know what needs to be passed to the constructor other than what they need to know (like the $definition, in this case).

Then, instead of the new to create, you can just hit this new static factory method, with something like:

$properties[$fieldname] = EntityReferenceWithUriProperty::createInstance($definition);

On another note, looks like there should be schema definitions for any properties...

An example of those in search_api proper: https://git.drupalcode.org/project/search_api/-/blob/8.x-1.x/config/schema/search_api.processor.schema.yml#L220-271

Where they seem to be targeted, from the index config entity: https://git.drupalcode.org/project/search_api/-/blob/8.x-1.x/config/schema/search_api.index.schema.yml#L40-41

Might get a little messy given what I think would correspond to the key there, dynamic property names as per $fieldname over at https://github.com/Islandora/islandora/pull/913/files#diff-a6e10f5851d0df552f0c1523868a930cc3aac263d2c54582694ff5f979977bccR123-R124 ?

Another potential alternative to deal with DI things could be to push off the building out of the lists of things another level, to define FormElements that are aware of what they can/should display (under the assumption that FormElement plugins can work with the ContainerFactoryPluginInterface themselves), then the "form building" in the config form shouldn't need to have things injected at all?